home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group98c.txt / 000118_icon-group-sender _Thu Dec 10 09:06:07 1998.msg < prev    next >
Internet Message Format  |  2000-09-20  |  3KB
  1. Return-Path: <icon-group-sender>
  2. Received: (from root@localhost)
  3.     by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id JAA06264
  4.     for icon-group-addresses; Thu, 10 Dec 1998 09:04:38 -0700 (MST)
  5. Message-Id: <199812101604.JAA06264@baskerville.CS.Arizona.EDU>
  6. From: swampler@noao.edu (Steve Wampler)
  7. Date: Tue, 8 Dec 1998 18:22:21 MST
  8. To: icon-group@optima.CS.Arizona.EDU
  9. Subject: Re: Past Keyword / Coexpr Help
  10. Errors-To: icon-group-errors@optima.CS.Arizona.EDU
  11. Status: RO
  12.  
  13. On Dec 8 at  5:23pm, MJE writes:
  14. } Steve Wampler wrote:
  15. } > 
  16. } > ...  You still
  17. } > have the overhead of procedure calling - there is no difference in the
  18. } > call to a user-supplied procedure and a built-in.
  19. } 
  20. } The logical requirements are identical but I'm sure you'll grant that C
  21. } overhead happens much faster than Icon interpreted overhead.
  22.  
  23. Well, yes and no.  It's the interpreter making the call in both cases,
  24. so argument pushing, stack adjustments, etc.  are the same.  Only after
  25. the call stack has been set up does a difference appear and that's
  26. not much more than setting the program counter.  Once you're in the
  27. C routine, things will go faster, but there are still all the type
  28. checks and type coercions that take place, plus the decomposition
  29. of Icon types into C types and back.  All of these happen in either
  30. case.  The amount of work done differently (i.e. in C instead of
  31. Icon) isn't that large of a percentage of the total work being done.
  32.  
  33. Don't be surprised if there isn't that much difference - the
  34. 'heart' of the code (find()) is coded in C either way.  Still, it
  35. would make a good experiment and I'll certainly grant that if you
  36. implemented find() in Icon versus calling the C you'd see a
  37. difference.
  38.  
  39. } I like your idea about an IPL pack.  However, you have not incited me to
  40. } commit an act of implementation.  What interests me instead is making
  41. } Icon parsing available in C language programs.
  42.  
  43. } For that I will need to write a bunch of COM objects.  That means
  44. } "Component Object Model" for those not in the know, Microsoft's upgrade
  45. } to the DLL concept.  I have been mulling over this project for a while. 
  46. } A little more mulling, and I might be incited to commit an act of
  47. } implementation.
  48.  
  49. That will be interesting and certainly useful for those of you running
  50. under Windows, but not much use to those of us who live in the non-MS
  51. world.
  52.  
  53. One thing to keep in mind is that in many Icon programs, the
  54. time spent in the interpreter is <10% of the total running time - most
  55. of the time is actually spent in C code.  We learned that when Cary
  56. Coutant wrote a compiler for Icon back in the 70's - the speed up
  57. wasn't spectacular.  It took Ken Walker's optimizing compiler work
  58. to show any significant improvement and even with that there was
  59. still a lot of work to be done.
  60.  
  61.  
  62. -- 
  63. Steve Wampler - swampler@gemini.edu [Gemini 8m Telescopes Project (under AURA)]
  64. The gods that smiled at your birth are now laughing openly. (Fortune Cookie)
  65.